昨天，我把 AI 避雷探針從 localhost 部署到 Firebase Hosting，原本以為網站上線後就可以正常使用，沒想到測試 Gemini AI 分析功能時卻出現問題。
網站可以正常開啟，店家搜尋等功能也能使用，但到了 AI 分析這一步就無法順利執行。
因此，今天的目標就是繼續追查這個問題，找出本地端可以使用、部署後卻無法使用的原因。

一、重新確認目前遇到的問題

先整理一下目前的狀況。

從這個結果可以看出，問題不一定出在整個網站，也可能集中在 Gemini API 的呼叫過程。
所以接下來不應該直接修改所有程式碼，而是先找出錯誤發生在哪一個環節。

二、使用瀏覽器開發者工具找錯誤

第一步，我重新開啟部署後的網站，並使用瀏覽器開發者工具檢查錯誤。
在 Chrome 中，可以按下 F12 開啟開發者工具。
接著主要檢查兩個地方：
** Console**
Console 可以查看 JavaScript 執行時出現的錯誤。
例如：

• API Key 沒有正確取得。
• JavaScript 程式執行失敗。
• Gemini API 回傳錯誤。
• 程式嘗試讀取不存在的資料。
  

三、檢查 Gemini API Key 與部署環境

第二步，我開始檢查 Gemini API 的相關設定。
在本地端開發時，程式可以透過原本的設定呼叫 Gemini；但部署到 Firebase Hosting 後，網站的執行環境已經改變，因此需要確認 API 是否仍然能正常使用。
這次主要檢查以下幾個方向：
1. API Key 是否正確
確認程式使用的 API Key 是否存在，以及是否有誤植或設定錯誤。

2. API Key 是否有限制使用網域
如果 API Key 有設定網站來源限制，就要確認 Firebase Hosting 使用的網域是否符合限制條件。
不過，是否需要調整限制，必須先看實際使用的 API Key 類型與錯誤訊息，不能直接認定一定是網域造成的。

3. 部署後是否仍然能取得必要設定
如果程式使用環境變數，就要確認建置與部署流程是否有正確帶入設定。
如果是直接在前端 JavaScript 使用設定值，也需要確認程式實際取得的內容是否正確。

另外，也要注意 API Key 的安全性。若直接將 Gemini API Key 放在公開網站的前端程式碼中，使用者可能透過瀏覽器開發者工具查看到它。
因此，正式上線時不能只考慮能不能呼叫 API，也要思考如何保護金鑰。較安全的做法是讓前端呼叫自己的後端或雲端函式，再由後端安全地呼叫 Gemini，並限制使用量。

四、不能只靠猜測修改程式碼

除錯過程中，我發現一個很重要的觀念：
遇到錯誤時，應該先確認原因，再決定要修改哪裡。

如果只是看到 Gemini 無法使用，就直接更換模型、重寫 API 呼叫或修改一堆設定，反而可能讓問題變得更複雜。
比較合理的排查順序是：

1. 確認網站本身可以正常執行。
2. 查看 Console 是否有 JavaScript 錯誤。
3. 查看 Network 是否有送出 Gemini API 請求。
4. 根據回傳的狀態碼與錯誤訊息判斷原因。
5. 檢查 API Key、網域限制及相關設定。
6. 修改後重新部署，再次測試。

如果遇到 400、403、404、429 或 500 等狀態碼，也不能全部當成同一種問題處理，必須搭配實際的錯誤訊息判斷。

五、重新測試線上版

完成檢查或修改後，還需要重新測試 Firebase Hosting 上的正式網站。
不能只在 localhost 確認成功，就認為問題已經解決。
我會再次操作完整流程：
店家搜尋 → 選擇店家 → 取得評論 → Gemini 分析 → 顯示避雷報告。
如果 Gemini 已經能正常回傳分析結果，就可以繼續測試報告內容是否正確顯示。
如果仍然失敗，就要保留最新的錯誤訊息，作為下一次排查的依據。
【實際操作圖 ：重新測試線上版 AI 避雷報告】

從網址可知，終於連上AI跑出報告了

六、今天的心得

這次的問題讓我發現，開發網站不只是把功能寫出來，還需要理解不同服務之間是怎麼連接的。
以前在本地端測試時，只要 Gemini 能正常分析評論，就會覺得這個功能已經完成。
但真正部署到線上後，才發現 API 設定、執行環境與金鑰管理都可能影響功能是否正常。
今天也讓我更了解瀏覽器開發者工具的用途。Console 可以協助找出 JavaScript 錯誤，而 Network 則可以查看請求是否送出，以及服務回傳了什麼結果。

除錯不是一直修改程式碼，而是透過錯誤訊息縮小問題範圍。